home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / pppext / pppext-minutes-92mar.txt < prev    next >
Encoding:
Text File  |  1993-02-17  |  7.7 KB  |  192 lines
  1. This is only a rough draft - Megan 04/20/92
  2.  
  3. 18 March 1992
  4.  
  5. Point-to-Point Protocol Extensions (pppext)
  6.  
  7. Chair:  Brian Lloyd, brian@lloyd.com
  8.  
  9. Mailing Lists:
  10.         General Discussion: ietf-ppp@ucdavis.edu
  11.                 To Subscribe: ietf-ppp-request@ucdavis.edu
  12.                 Archive: ucdavis.edu:archive/ppp-archive
  13.  
  14.         IETF PPP
  15.  
  16.         *Appletalk
  17.         *LQM
  18.         *MIB
  19.         *IPX
  20.         *Decnet
  21.         *CLNP
  22.         *Physical Layer
  23.  
  24. Brian Lloyd distributed a memo titled "The PPP Internetwork Packet
  25. Exchange (IPX) Control Protocol" submitted by Novell.  Karl Fox
  26. distributed a PPP Pocket Reference card from Morningstar Technologies.
  27.  
  28. There will be a delay in the issuance of an RFC for LCP, IPCP, and
  29. Authentication due to an oversite within the IAB.  However, there
  30. are not going to be any changes to the drafts prior to becoming RFCs.
  31. So it is safe to implement, and still be in compliance.
  32.  
  33. Questions re: IP Address Negotiation.  The implementor needs to
  34. support old format until PPP becomes a full standard.  First check to
  35. see if the peer is using the old format.  If so, negotiate IP
  36. addressing using the old algorithm.  This procedure applies until PPP
  37. is a full standard.  After that, support will not be provided for old
  38. algorithm for IP address negotiation.  If you do IP you need to go
  39. ahead and do the new IP address negotiation scheme.
  40.  
  41. Each of LCP, IP Control, LQM, and Authentication have their own
  42. document.
  43.  
  44. Brian asked, "how many here are actively working to implement PPP?"
  45. Approximately 12 hands went up.
  46.  
  47. As for penetration in the market it was noted that BARRNet now runs
  48. PPP on links to member sites.
  49.  
  50. APPLETALK
  51.  
  52. Brad Parker of Cayman presented an updated draft of his Appletalk over
  53. PPP document.  Feedback from Bill Simpson and Chris Ranch of Novell.
  54. The document was forwarded to the IETF drafts mailing list.  Good
  55. review from Appletalk community, supports ARAP.  Will support router
  56. to router half routing.  Doc will be placed on Merit.edu and
  57. Angband.stanford.edu in addition to usual places.
  58.  
  59. LINK QUALITY MONITORING (LQM)
  60.  
  61. The previous version of LQM was not widely implemented so major
  62. changes were deemed acceptable (this choice was made at the Santa Fe
  63. IETF meeting).  As a result the general mechanism was redefined.
  64. should be able to determine if a synchronous link is up.  Flow control
  65. monitoring not recommend for async.  LQM is useful for high speed
  66. point to point between router vendors.  LQM will give continuous state
  67. of the link info.  This is good for OSPF type link state relative
  68. protocols.
  69.  
  70. PPP MIB
  71.  
  72. Frank Kastenholz of Clearpoint (kasten@clearpoint.com) updated MIB for
  73. PPP.  Discussion has been open on the mailing list.  Frank presented
  74. an update. PPP is a complex protocol so the MIB grew to almost 200
  75. variables.  Frank says this MIB has to be trimmed down, but others are
  76. asking for more.  This MIB doesn't even address Appletalk, Decnet,
  77. CLNP.
  78.  
  79. Should this MIB cover NCPs? was asked.
  80.  
  81. Frank drew on the overhead.  There were four columns: Protocol,
  82. Mandatory, Conditional Mandatory (if you are trying to control PPP
  83. instead of just monitor), and Optional.  This graph allowed the
  84. members of the WG to assign each variable to a category.
  85.  
  86. One reason to have lots of MIB variables is the need to configure PPP
  87. in routers via SNMP (the router from NAT was used as an example since
  88. it is only manageable via SNMP).  It was suggested that all
  89. configuration variables be in the optional column and get rid of the
  90. Conditional Mandatory column.
  91.  
  92. Discussion continued as to how necessary it might be to trim down the
  93. variables.  It was determined that MIB variables present for debugging
  94. purposes be discarded.  Brian requested that Frank Kastenholz, Bill
  95. Simpson, and Glenn McGregor meet to pare down the MIB prior to the
  96. next day's WG meeting.
  97.  
  98. IPX
  99.  
  100. Christopher Ranch of Novell took the floor to lead the discussion of
  101. IPX over PPP.  The Novell NCP has no options and this is in conflict
  102. with what Shiva has proposed.  Brian recommended that Novell and Shiva
  103. hammer out the differences and produce a single unifying document.
  104. The working group indicated that they wanted to see an address
  105. negotiation and a compression option added to Novell's proposal.
  106. Brian also asked Chris to consider adding negotiation of a routing
  107. protocol IF he thinks it would be useful.
  108.  
  109. DECNET
  110.  
  111. There appeared to be no progress in the area of DECNet over PPP.
  112. Further work on this subject is awaiting an implementation and/or a
  113. new draft document.
  114.  
  115. OSI/CLNP
  116.  
  117. Bill opened discussion with the remark that there is a well-written
  118. document for which there are no implementations.  This is a no-option
  119. document that differentiated between the three different kinds of
  120. CLNP.  This will be re-addressed when there is an implementation.
  121. Christopher Ranch will forward requests on this to the correct person
  122. at Novell who is beginning an implementation.
  123.  
  124. BRIDGING
  125.  
  126. Fred Baker is looking for implementation experiences to document.
  127. 3-COM has done bridging over PPP.  Currently the document needs to
  128. 1) clarify the concept of a virtual ring, and
  129. 2) tighten up the language.
  130.  
  131. 19 March 1992 09:00
  132.  
  133. 32-BIT FCS
  134.  
  135. Bill Simpson stated the issues with 32-bit FCS.  These being that DEC
  136. owns patents on a procedure of combining the 32bit and 16bit FCS into
  137. a 48bit FCS to be used while 32bit FCS is being negotiated.  Noel
  138. Chiappa said that DEC will make a license to their process freely
  139. available.  DEC will provide a general grant of right to use the
  140. technology and will provide a letter to the IETF stating so.
  141.  
  142. Action item:  Karl Fox of Morningstar Technologies, being
  143. a vendor of a company with an implementation, is going to take the
  144. task of getting the letter from DEC releasing the rights to the
  145. process to the world.
  146.  
  147. PHYSICAL LAYER
  148.  
  149. Where/how to handle the physical layer information.  The PPP mailing
  150. list concluded that the LCP layer is not the place.  Bill Simpson
  151. stated that PPP is supposed to run over anything; in other words if
  152. you have two wires you should be able to run PPP.  Brian Lloyd
  153. suggested the need for an implementation reference.  There was
  154. agreement to this.  Someone said this should be an informational RFC.
  155. Items to be covered included: PPP SYNC interface with an eye towards
  156. RS232, V35, V36, RS422/RS449; async implementations; switched
  157. circuits, i.e. Hayes compatible, X21, V25bis dialing; and definition
  158. of physical layer up/down determination; etc.
  159.  
  160. Questions presented:
  161.  
  162. How are we going to deal with ISDN?  This is a topic of future
  163. discussion and work with the IPLPDN WG.
  164.  
  165. Chat scripts and dealing with a login sequence on an async link.  What
  166. is the other end going to send?
  167.  
  168. MIB REVISITED
  169.  
  170. Frank took the floor to revisit the issue of MIB variables.  Together
  171. with Bill Simpson, Glenn McGregor, and some input from Jeff Case they
  172. got the number of variables to just over a hundred.  This is down from
  173. 196.  They did not deal with every section, and some still need to be
  174. added for Appletalk, and IPX.  It will be necessary to know if and
  175. what will be monitored in IPX over PPP.
  176.  
  177. Changes: link extensions table is gone, FSM table(s) are gone, these
  178. were deemed to be debugging information.  It was decided that it made
  179. more sense to return the link quality reports as a single aggregate
  180. MIB variable instead of permitting each field withing the LQR to be
  181. queried separately.  Individual variables in the LQR are not very
  182. useful by themselves plus in order to make sense of the timely
  183. information it is necessary to see a complete "snapshot" in one
  184. operation.
  185.  
  186. On the philosophy of configurable parameters: the choice seems to be,
  187. a rich set of "knobs" or allowing the vendor to completely control the
  188. initial and desired state of the implementation.  There was no
  189. hard-and-fast decision so it was left up to Frank to clean up what was
  190. decided and to post all changes to the MIBs to the mailing list in a
  191. few weeks where discussion will begin anew.
  192.